home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-ietf-madman-networkmib-00.txt < prev    next >
Text File  |  1993-06-07  |  15KB  |  436 lines
  1.  
  2.                             Internet Draft
  3.                     Network Services Monitoring MIB
  4.  
  5.                           MADMAN Working Group
  6.                               May 17, 1993
  7.                        Expires: November 17, 1993
  8.  
  9. Status of this Memo
  10.  
  11. This document is an Internet Draft. Internet Drafts are working
  12. documents of the Internet Engineering Task Force (IETF), its Areas,
  13. and its Working Groups. Note that other groups may also distribute
  14. working documents as Internet Drafts.
  15.  
  16. Internet Drafts are draft documents valid for a maximum of six 
  17. months.    Internet Drafts may be updated, replaced, or obsoleted by
  18. other documents at any time.  It is not appropriate to use Internet
  19. Drafts as reference material or to cite them other than as a "working
  20. draft" or "work in progress."
  21.  
  22. Please check the I-D abstract listing contained in each Internet 
  23. Draft directory to learn the current status of this or any  other
  24. Internet Draft.
  25.  
  26. Abstract
  27.  
  28. This document defines the generic part of a MIB suitable for
  29. monitoring applications which provide some kind of network services.
  30. This MIB is intended to be extended to accomodate monitoring specific
  31. to a given type of service, for example, a Message Transfer Agent
  32. (MTA) service or a Directory Service Agent (DSA) service.
  33.  
  34. Rationale for having an Network Services Monitoring MIB
  35.  
  36. There is a substantial need to monitor applications which provide
  37. network services, particularly distributed components such as MTAs and
  38. DSAs, in order to measure load and to detect broken connectivity,
  39. system failure, congestion, and other types of problems. Specific
  40. requirements include:
  41.  
  42. (1) General monitoring of a large number of components (typical
  43.     for a large organization).
  44. (2) Integration with general network management.
  45.  
  46. SNMP is the clear choice for this function.  At present only simple
  47. read-only access is defined; this is sufficient to determine up/down
  48. status and provide an indication of a broad class of operational
  49. problems.   
  50.  
  51. Restriction of Scope
  52.  
  53. The framework provided here is very minimal; there is a lot more that
  54. could be done. For example:
  55.  
  56. (1) General network service application configuration.
  57. (2) Detailed examination and modification of individual entries in
  58.     service-specific request queues.
  59. (3) Probing to determine the status of a specific request (e.g. the
  60.     location of a mail message with a specific message-id).
  61. (4) Requesting that certain action be performed (e.g. forcing an
  62.     immediate connection and transfer of pending messages to some
  63.     specific system).
  64.  
  65. Whilst all these capabilities are both impressive and useful, to be
  66. effective, security is an absolute requirement. These capabilities
  67. also mandate a much more complex design with many characteristics
  68. likely to be fairly implementation-specific. As a result such
  69. facilities are likely to be both contentious and difficult to
  70. implement. 
  71.  
  72. This document religiously keeps things simple and focuses on the basic
  73. monitoring aspect of managing applications providing network services. 
  74. The goal here is to provide a framework which is simple, useful, and
  75. widely implementable.
  76.  
  77. Relationship to Directory Services
  78.  
  79. Use of and management of directory services already is tied up with
  80. network service application management.  There are clearly many things
  81. which could be dealt with by directory services and protocols.  We
  82. take the line here that static configuration information is both
  83. provided by and dealt with by directory services and protocols. The
  84. emphasis here is on transient application status.
  85.  
  86. By placing static information in the directory, the richness and
  87. linkage of the directory information framework does not need to be
  88. repeated in the MIB.  Static information is information which has a
  89. mean time to change of the order of days or longer.
  90.  
  91. When network service applications that employ directory services
  92. are monitored, it is recommend that a linkage be established, so
  93. that:
  94.  
  95. (1) The managed object contains its own directory name.  This
  96.     allows all directory information to be obtained by reference.
  97.     This will let a SNMP monitor capable of performing directory
  98.     queries present this information to the manager in an
  99.     appropriate format.  It is intended that this will be the
  100.     normal case. 
  101. (2) The directory will reference the location of the SNMP agent,
  102.     so that an SNMP capable directory query agent could probe
  103.     dynamic characteristics of the object.  
  104. (3) This approach could be extended further, so that the SNMP
  105.     attributes are modelled as directory attributes.  This would
  106.     dramatically simplify the design of directory service agents
  107.     that use SNMP to obtain the information they need.
  108.  
  109. Application Objects
  110.  
  111. This MIB starts with a set of general purpose attributes which would
  112. be appropriate for a range of applications that provide network
  113. services.  Both OSI and non-OSI services can be accomodated.
  114. Additional tables defined in extensions to this MIB provide attributes
  115. specific to specific network services.
  116.  
  117. A table is defined which will have one row for each network service
  118. application running on the system.  The only static information held
  119. on the application is its distinguished name.  All other static
  120. information should be obtained from various directory services.  The
  121. Directory Name is an external key, which allows an SNMP MIB entry to
  122. be cleanly related to the X.500 Directory.  In SNMP terms, the
  123. applications are grouped in a table called applTable, which is indexed
  124. by an integer key applIndex.
  125.  
  126. The type of the application will be determined by one or both of:
  127.  
  128. (1) Additional MIB variables specific to the applications.
  129. (2) An association to the application of a specific protocol.
  130.  
  131. APPLICATION-MIB DEFINITIONS ::= BEGIN
  132.  
  133. IMPORTS
  134.   OBJECT-TYPE FROM RFC1212
  135.   experimental, Counter, Gauge, TimeTicks FROM RFC1151-SMI
  136.   DisplayString FROM RFC1213-MIB;
  137.  
  138. application-mib OBJECT IDENTIFIER ::= {experimental xxx}
  139.  
  140. applTable OBJECT-TYPE
  141.     SYNTAX SEQUENCE OF ApplEntry
  142.     ACCESS not-accessible
  143.     STATUS mandatory
  144.     DESCRIPTION
  145.         "The table holding objects which apply to all different
  146.          kinds of applications providing network services."
  147.     ::= {application-mib 1}
  148.  
  149. applEntry OBJECT-TYPE
  150.     SYNTAX ApplEntry
  151.     ACCESS not-accessible
  152.     STATUS mandatory
  153.     DESCRIPTION
  154.       "An entry associated with a network service application."
  155.     INDEX {applIndex}
  156.     ::= {applTable 1}
  157.  
  158. ApplEntry ::= SEQUENCE {
  159.     applIndex
  160.         INTEGER,
  161.     applName
  162.         DisplayString,
  163.     applVersion
  164.         DisplayString,
  165.     applOperStatus
  166.         INTEGER,
  167.     applLastChange
  168.         TimeTicks,
  169.     applInboundAssociations
  170.         Gauge,
  171.     applOutboundAssociations
  172.         Gauge,
  173.     applAccumulatedInboundAssociations
  174.         Counter,
  175.     applAccumulatedOutboundAssociations
  176.         Counter,
  177.     applLastInboundActivity
  178.         TimeTicks,
  179.     applLastOutboundActivity
  180.         TimeTicks,
  181.     applFailedOutboundAssociations
  182.         Counter
  183.     applRejectedInboundAssociations
  184. }
  185.  
  186. applIndex OBJECT-TYPE
  187.     SYNTAX INTEGER (1..2147483647)
  188.     ACCESS read-only
  189.     STATUS mandatory
  190.     DESCRIPTION
  191.       "An index to uniquely identify the network service
  192.        application."
  193.     ::= {applEntry 1}
  194.  
  195. applName
  196.     SYNTAX DisplayString
  197.     ACCESS read-only
  198.     STATUS mandatory
  199.     DESCRIPTION
  200.       "The name the network service application chooses to be
  201.        known by."
  202.     ::= {applEntry 2}
  203.  
  204. applVersion
  205.     SYNTAX DisplayString
  206.     ACCESS read-only
  207.     STATUS mandatory
  208.     DESCRIPTION
  209.       "The version of network service application software."
  210.     ::= {applEntry 3}
  211.  
  212. applOperStatus OBJECT-TYPE
  213.     SYNTAX INTEGER {
  214.       up(1),
  215.       down(1),
  216.       halted(3),
  217.       congested(4),
  218.       restarting(5)
  219.     }
  220.     ACCESS read-only
  221.     STATUS mandatory
  222.     DESCRIPTION 
  223.       "Indicates the operational status of the network service
  224.        application. 'down' indicates that the network service is
  225.        not available. 'running' indicates that the network service
  226.        is operational and available.  'halted' indicates that the
  227.        service is operational but not available.  'congested'
  228.        indicates that the service is operational but no additional
  229.        inbound associations can be accomodated.  'restarting'
  230.        indicates that the service is currently unavailable but is
  231.        in the process of restarting and will be available soon."
  232.     ::= {applEntry 4}
  233.  
  234. applLastChange OBJECT-TYPE
  235.     SYNTAX TimeTicks
  236.     ACCESS read-only
  237.     STATUS mandatory
  238.     DESCRIPTION
  239.       "The value of sysUpTime at the time the network service
  240.        application entered its current operational state.  If"
  241.        the current state was entered prior to the last
  242.        initialization of the local network management subsystem,
  243.        then this object contains a zero value."
  244.     ::= {applEntry 5}
  245.  
  246. applInboundAssociations OBJECT-TYPE
  247.     SYNTAX Gauge
  248.     ACCESS read-only
  249.     STATUS mandatory
  250.     DESCRIPTION
  251.       "The number of current associations to the network service
  252.        application, where it is the responder.  For dynamic single
  253.        threaded processes, this will be the number of application
  254.        instances."
  255.     ::= {applEntry 6}
  256.  
  257. applOutboundAssociations OBJECT-TYPE
  258.     SYNTAX Gauge
  259.     ACCESS read-only
  260.     STATUS mandatory
  261.     DESCRIPTION
  262.       "The number of current associations to the network service
  263.        application, where it is the initiator.  For dynamic single
  264.        threaded processes, this will be the number of application
  265.        instances."
  266.     ::= {applEntry 7}
  267.  
  268. applAccumulatedInboundAssociations OBJECT-TYPE
  269.     SYNTAX Counter
  270.     ACCESS read-only
  271.     STATUS mandatory
  272.     DESCRIPTION
  273.       "The total number of associations to the application entity
  274.        since application initialization, where it is the responder.
  275.        For  dynamic single threaded processes, this will be the
  276.        number of application instances."
  277.     ::= {applEntry 8}
  278.  
  279. applAccumulatedOutboundAssociations OBJECT-TYPE
  280.     SYNTAX Counter
  281.     ACCESS read-only
  282.     STATUS mandatory
  283.     DESCRIPTION
  284.       "The total number of associations to the application entity
  285.        since application initialization, where it is the initiator.
  286.        For dynamic single threaded processes, this will be the
  287.        number of application instances."
  288.     ::= {applEntry 9}
  289.  
  290. applLastInboundActivity OBJECT-TYPE
  291.     SYNTAX TimeTicks
  292.     ACCESS read-only
  293.     STATUS mandatory
  294.     DESCRIPTION
  295.       "The time since this application has had an inbound
  296.        association."
  297.     ::= {applEntry 10}
  298.      
  299. applLastOutboundActivity OBJECT-TYPE
  300.     SYNTAX TimeTicks
  301.     ACCESS read-only
  302.     STATUS mandatory
  303.     DESCRIPTION
  304.       "The time since this application has had an outbound
  305.        association."
  306.     ::= {applEntry 11}
  307.  
  308. applFailedOutboundAssociations OBJECT-TYPE
  309.     SYNTAX Counter
  310.     ACCESS read-only
  311.     STATUS mandatory
  312.     DESCRIPTION
  313.       "The total number associations where the application entity
  314.        is initiator and association establishment has failed,
  315.        since application initialization."
  316.     ::= {applEntry 12}
  317.  
  318. applRejectedInboundAssociations OBJECT-TYPE
  319.     SYNTAX Counter
  320.     ACCESS read-only
  321.     STATUS mandatory
  322.     DESCRIPTION
  323.       "The total number inbound associations the application entity
  324.        has rejected, since application initialization."
  325.     ::= {applEntry 12}
  326.  
  327. -- The basic applTable contains a list of the application entities.
  328. -- A second table is maintained, which holds the list of
  329. -- associations.  This is treated as a separate group to the basic
  330. -- application table.  Where simplified appplication monitoring is
  331. -- needed, the assocTable group may be omitted. This table is
  332. -- indexed by applIndex and assocIndex, with the application index
  333. -- coming first.   
  334.  
  335. assocTable OBJECT-TYPE
  336.     SYNTAX SEQUENCE OF AssocEntry
  337.     ACCESS not-accessible
  338.     STATUS mandatory
  339.     DESCRIPTION
  340.         "The table holding a set of all active application
  341.          associations."
  342.     ::= {application-mib 2}
  343.  
  344. assocEntry OBJECT-TYPE
  345.     SYNTAX AssocEntry
  346.     ACCESS not-accessible
  347.     STATUS mandatory
  348.     DESCRIPTION
  349.       "An entry associated with an association for a network
  350.        service application."
  351.     INDEX {applIndex, assocIndex}
  352.     ::= {assocTable 1}
  353.  
  354. AssocEntry ::= SEQUENCE {
  355.     assocIndex
  356.         INTEGER,
  357.     assocRemoteApplication
  358.         DisplayString,
  359.     assocApplicationProtocol
  360.         OBJECT IDENTIFIER,
  361.     assocApplicationType
  362.         INTEGER,
  363.     assocDuration
  364.         TimeTicks
  365. }
  366.  
  367. assocIndex OBJECT-TYPE
  368.     SYNTAX INTEGER (1..2147483647)
  369.     ACCESS read-only
  370.     STATUS mandatory
  371.     DESCRIPTION
  372.       "An index to uniquely identify each association for a network
  373.        service application."
  374.     ::= {assocEntry 1}
  375.  
  376. assocRemoteApplication OBJECT-TYPE
  377.     SYNTAX DisplayString
  378.     ACCESS read-only
  379.     STATUS mandatory
  380.     DESCRIPTION
  381.       "The name of the system running remote network service
  382.        application.  For an IP-based application this should be
  383.        either a domain name or IP address.  For an OSI application
  384.        it should be the string encoded distinguished name of the
  385.        managed object using the format defined in RFC-?.  For
  386.        X.400(84) MTAs which do not have a Distinguished Name, the
  387.        RFC-1327 syntax 'mta in globalid' should be used."
  388.     ::= {assocEntry 2}
  389.  
  390. assocApplicationProtocol OBJECT-TYPE
  391.     SYNTAX OBJECT IDENTIFIER
  392.     ACCESS read-only
  393.     STATUS mandatory
  394.     DESCRIPTION
  395.       "An identification of the protocol being used for the
  396.        application.  For an OSI Application, this will be the
  397.        Application Context.  For Internet applications, the IANA
  398.        maintains a registry of the OIDs which correspond
  399.        to well-known applications.  If the application protocol is
  400.        not listed in the registry, the value {applProtoID port} is
  401.        used where 'port' corresponds to primary port being used by
  402.        the application."
  403.     ::= {assocEntry 3}
  404.  
  405. assocApplicationType OBJECT-TYPE
  406.     SYNTAX INTEGER {
  407.         ua-initiator(1),
  408.         ua-responder(2),
  409.         peer-initiator(3),
  410.         peer-responder(4) }
  411.     ACCESS read-only
  412.     STATUS mandatory
  413.     DESCRIPTION 
  414.       "Shows whether the remote application is a User Agent, or a
  415.        peer server, and whether the remote end is initiator or
  416.        responder."
  417.     ::= {assocEntry 4}
  418.  
  419. assocDuration OBJECT-TYPE
  420.     SYNTAX TimeTicks
  421.     ACCESS read-only
  422.     STATUS mandatory
  423.     DESCRIPTION
  424.       "The time that the association has been open."
  425.     ::= {assocEntry 5}
  426.  
  427. applProtoID OBJECT IDENTIFIER ::= {application-mib 3}
  428.  
  429. END
  430.  
  431. A means will be defined to allocate an object identifier to each TCP
  432. application.  This will be done in consultation with the IANA.
  433.  
  434. Expires: November 17, 1993
  435.  
  436.